There are several methods used to connect an electronic instrument to a computer system, and three are very commonly used. The first is to connect the instrument to a computer over an IEEE 488 bus, also called the Hewlett Packard Interface Bus or the General Purpose Interface Bus. Another commonly used interface is the RS-232 serial communications interface. A third commonly used interface is the direct connection of the instrument to the computer system internal memory bus. An example of this third interface is the interface definition for an instrument connected to the VXI bus, as provided by National Instruments Corporation.
These three interfaces use considerably different commands to control an electronic instrument. Because of the variety of commands, if a program running in a computer system wishes to control an instrument, the programmer must decide which of the interfaces the instrument will use for connection, so that the correct programming commands can be used. This significantly reduces the portability of the program used to control the instrument, since the program must be rewritten if the instrument is connected via a different interface from the one originally programmed. This rewriting takes significant amounts of programmer time. It also means that three different sets of software must be shipped to access the instrument, one for each of the instrument interfaces.
Another problem exists when multiple computer systems, using different operating systems, are involved. The commands necessary to access the instrument over the various interfaces are often different for each operating system used. For example, the commands necessary to access an instrument over an RS-232 interface in the MS-DOS operating system (MS-DOS is a registered trademark of MicroSoft Corporation) are different from the commands necessary to access an instrument over an RS-232 interface in the Unix operating system (Unix is a registered trademark of AT & T). Therefore, not only must there be a separate program for each interface, there must be a separate program for each interface with each operating system to which the instrument may be connected.
Another problem caused by connecting through multiple interfaces and multiple operating systems is the need for the program to have the interface address defined within the program. Thus, only one address can conveniently be used with each combination of interface and operating system. If an instrument is not located at the address anticipated by the software, a different version of the software must be created and sent to the instrument user, causing considerable expense and delay.
One prior art instrument interface, the Hewlett Packard Device I/O Library (DIL), provides an input/output library of functions that can be used to access an instrument only with the Hewlett-Packard HPUX operating system environment. As an example of the problems identified above, the Device I/O Library has separate sets of commands for each of the interfaces.
Some of the interface commands could not be implemented in certain operating systems. For example, in the Unix operating system a user process issues a lock command to obtain exclusive control of a device such as an instrument. In the MS-DOS operating system, however, every process always has exclusive control of all input/output devices, therefore, the lock command is not only unnecessary, it is not implemented.
One of the most significant features of higher level programming languages is the ability to format data automatically before sending that data to an input/output device. For example, format statements originated with the Fortran language in the late 1950's. Typically, format statements convert integer numbers and floating point numbers in various formats into a displayable or printable format that can easily be understood by people. Thus formatted input/output has been typically used for printing information on a printer or displaying information on a terminal. In prior art systems, this capability can only be made available with instrument data by first formatting the data into a memory buffer and then sending the memory buffer contents to the instrument. Furthermore, current formatting capability cannot create numbers in special formats as required by the IEEE 488 interface standard.
It is thus apparent there is need in the art for an improved instrument programming interface that is independent of the particular electrical interface used to connect the instrument to the computer system. There is further need in the art for such a system that is also independent of the particular operating system being used to execute the program. A still further need is for such an interface that has formatted I/O capability, including the special formats of IEEE 488. The present invention meets these and other needs.